Transactions carried out across unprotected networks such as the Internet enable increased service availability and higher convenience at all levels. The Internet has been utilized for a significant amount of commercial and personal communication in nearly all regions of the world. Governments across the world are aiming to provide Internet-enabled services to their citizens. In order for the Internet to be used to conduct sensitive operations, each party involved in a transaction or communication has to be capable of confirming their identity in a trusted way. Data protection is also important to ensure secure and trustworthy transactions.
It is challenging to implement efficient solutions which address the above-noted security requirements and those currently being utilized raise ongoing concerns. As a result, the reputation of transactions over unprotected networks continues to suffer as the systems widely deployed today remain vulnerable to increasingly sophisticated attacks.
Traditional techniques used to secure Internet-based infrastructures often utilize a public key infrastructure (PKI) scheme. In operation, a user disposes of a unique public key pair certified by a trusted body, such as the certification authority, which delivers a digital certificate. While one of the two keys is made publicly available, the second one must be kept secret from everybody else as it will enable its respective owner to prove their identity and use it for authentication and/or signature purposes. FIG. 2 illustrates an overview of such keys, certificates and certificate authorities, which may be used in such a PKI scheme. FIG. 2 illustrates the use of such keys, certificates and certificate authorities for signing, encrypting and decrypting communications.
In a secure deployment, there will be clients, services and certificate authorities. Each of these entities is associated with public and private keys and certificates. Each party has a private key and a corresponding public key. A message encrypted using a public key can only be decrypted and read using the corresponding private key. This allows the client to send a message that only the server can read. A message signed with a private key can be checked using the corresponding public key. If the message has been changed after signing, then the check will fail. This procedure allows the server to confirm that the message was really sent by the client.
As illustrated in FIG. 2, there are three public-private key-pairs, one for each party. The client 220 uses a copy 215 of the server's public key 206 to encrypt 214 the request, and its own private key 219 to sign 218 the request. The server 208 uses a copy 209 of the client's public key 221 to check 212 the signature, and its own private key 210 to decrypt 211 the signature. Such a procedure provides a secure data transaction, provided that both parties can obtain the required public keys. Although it does not matter if a third party obtains access to the public keys, it does matter that the third party has the correct public keys. If an attacker gives the server their public key, pretending to be the client, then the server will accept messages sent by the attacker. Likewise, if the client wants to send a message to a server, but uses the attacker's public key instead of the server's public key, then the client will send messages that the attacker can read. To prevent unauthorized access, the public keys are paired with a certificate providing the identity of the owner of the private key.
The server and client public key and certificate bundles 221 and 206 are signed 203 and 204 by a certificate authority's 200 private key 201 to confirm that the details are correct. The effect of this procedure is that each party only needs to obtain the certification authority's public key 202 by some trusted mechanism, and can use that to verify any other keys. FIG. 2 illustrates the example of only one certification authority (CA). In more complicated situations, the client and server might have their certificates signed by different CAs. In that case, each must trust the CA that signed the other party's certificate. Also, FIG. 2 only illustrates the request message. The response would be signed and encrypted by the service and checked and decrypted by the client in a similar manner.
Even with correctly signed client's and server's public key and certificate bundles, one skilled in such a communication system would quickly discover that absolute privacy of each party's private key is fundamental to public key infrastructure. If an attacker gets a hold of any of the private keys it's quite simple to then assume that party's role. If, for example, the private key of a party is stored on a common storage device of the party an attacker can obtain access, then the private key may be accessed by simply mirroring the storage device.
Taking into account that today's commonly used multi-purpose electronic devices, such as personal computers (PCs) or mobile devices, are not considered secure enough to hold such keys, most institutions with stringent security levels choose to store the private keys on external chips embedded on pocket-sized cards with integrated circuits. For example, smart cards, chip cards or integrated circuit cards may be used to store private keys. There are two broad categories of smart cards. Memory cards only contain non-volatile memory storage components and occasionally dedicated security logic. Microprocessor cards additionally contain volatile memory and microprocessor components. Memory cards provide storage capabilities and an input/output interface. Cryptographic microprocessor cards allow for the supported cryptographic algorithms to be performed on the hardware itself.
The tamper resistance of known smart card architectures is based on a high level of miniaturization which makes physical disassembly difficult. Also, sophisticated software architectures, such as a proprietary operating system may offer additional security. Although some of these techniques already provide a high level of security they also have common disadvantages caused by their design. Memory and processor cards simply relocate the storage of the sensible private key from one seemingly secure physical device to another. As the secure device is small and portable the responsibility for securing the private key is simply shifted along to the customer. The high level of miniaturization requires prefabrication of large numbers of anonymous cards, which requires unique characteristics of the final customer, such as a fingerprint. Those unique characteristics may be stored in the card memory but cannot be part of the card's electrical circuits as this would lead to large costs and time for production.
Solutions which are based on smart cards still seem practical from a security point of view, however, there are additional disadvantages which prevent large scale deployment. The external medium which carries the chip containing the private key may be lost or stolen. As the secret memory of the smart card then can be attacked for an unlimited time period with an ordinary stock-commercial card reader in combination with free available libraries, it is possible to crack the private key, clone and manipulate the card.
Built-in smart card readers are not a de facto standard on PCs and laptops. There is no widespread communication standard on the market that can enable computers and chip cards to interact together in a seamless manner. Therefore, to make use of the chip card, the end user has to acquire a smart card, a smart card reader and install the reader on the computer. This is both time consuming and expensive. The convenience and portability offered by the Internet are considerably reduced. When the end user has to carry small pieces of hardware to retain control over the computer, the advantages of to such a system are questionable when compared to less secure legacy systems.
Although virtualization of physical smart card components, smart card specific operating systems, communication, encryption and decryption are disclosed in detail all known techniques do not address the problem on how to successfully relocate components of a real smart card to a virtual environment without loosing any of the advantages of a physically present external device.